1. Field of the Invention
The present invention relates to an index structure of metadata provided for searching for information on contents and a method for providing indices of the metadata, and a method and an apparatus for searching for the metadata using the index structure of the metadata. More particularly, the present invention relates to an index structure of metadata containing information on a key, at least a part of which is encoded so as to allow information on contents to be more efficiently searched when the XML metadata for the digital contents defined in TV-Anytime Forum (hereinafter referred to as “TVA”) (hereinafter referred to as “TVA metadata”) is divided into fragments in an independent unit and transmitted on a fragment basis, a method for providing indices of the metadata, and a method and an apparatus for searching the metadata using the indices of metadata.
2. Description of the Related Art
The TV-Anytime Forum is a private standardization organization established in September 1999 with the purpose of developing standards for providing audiovisual related services in a user-friendly environment such as a personal digital recorder (PDR) having a high volume personal storage device. Specifically, the aim of the services is to enable all the users to view and listen to various types of programs (such as conventional broadcasting services, online interactive services and the like) at a desired time and in a desired manner based on the personal storage device.
The TV-Anytime Forum has operated Working Groups for business models, system/transmission interfaces/contents referencing, descriptions, metadata, rights management and protection and the like, in order to establish standardization. With respect to the metadata concerned in the present invention, “1st Draft of Metadata Specification SP003v1.3” up to June 2002 has been published.
A configuration of the PDR will be briefly described with reference to FIG. 1. The PDR 100 receives video/audio signals and metadata via a variety of networks such as sky waves, satellite waves, internet networks and the like from a provider 200 for providing video/audio signals, collects viewing and listening patterns, and personal tastes of users, if necessary, and transmits them to the provider 200 for providing the video/audio signals. The PDR 100 comprises a high volume storage device for storing therein the received video/audio signals and metadata. The PDR 100 further comprises software for storage and reproduction of the video/audio signals, and an electronic program guide (EPG) application for retrieving and displaying metadata for the video/audio signals. The user ascertains the metadata for the video/audio data, i.e., titles of the programs, program reproduction times and the like, through a grid guide screen of the EPG application shown in FIG. 2, selects a desired program, and receives it via the network in real time or reproduces the video/audio data previously stored in the high volume storage device.
The metadata refer to data describing contents such as titles and synopses of programs, and are defined as “data about data.” In the TVA metadata specifications of the TV-Anytime Forum, its structure is defined by use of XML schema language (see XML 1.0 of W3C), the standard by the W3C (a consortium for promoting standards for the XML), and the semantics and attributes of the respective metadata elements are also defined. The TVA metadata relevant to broadcasting contents are configured with an XML document having a root node, “TVAMain (300)” as shown in FIG. 3. The TVA metadata relevant to programs are configured with, for example, nodes such as ProgramInformation Table, GroupInformation Table, ProgramLocation Table, ServiceInformation Table and the like, under the node of “ProgramDescription.”
In the TV-Anytime Forum, the TVA metadata are transmitted on a fragment basis as an independent unit in order to transmit a large volume of TVA metadata in a stream format. The concept of fragments will be briefly described with reference to FIG. 4. The fragments are obtained by dividing the TVA metadata configured with the XML documents shown in FIG. 3 into predetermined tree structures. For example, where the entire TVA metadata are divided into a tree structure (fragment TVAMain) including an upper node of “TVAMain” and predetermined child nodes under this upper node, a tree structure (fragment ProgramInformation) including an upper node of ProgramInformation Table and child nodes under this upper node, a tree structure (fragment BroadcastEvent) including an upper node of the BroadcastEvent Information and child nodes under this upper node, each of the divided tree structures becomes a fragment. The fragments can be transmitted independently of the other fragments, and the fragments can be accessed individually.
For individual access to the fragments, it is necessary to know a node referenced by a transmitted TVA metadata fragment, i.e., a node corresponding to the upper node of the TVA metadata fragment, in the entire metadata tree structure, and to describe relative paths in the TVA metadata fragments of keys contained in the transmitted TVA metadata fragment. To this end, XPath, which is a syntax for describing a path to one or more nodes in an XML document defined by W3C, is used. The term ‘key’ refers to a specific field of the metadata used for indexing, and also means child nodes of a node referenced by a fragment. Fields (for search conditions) input by the user, such as ‘Service ID’ and ‘Published Time,’ correspond to the keys.
In order to provide efficient search for and access to fragments, an index structure for the keys included in the metadata fragments is additionally required, and information on the index structure, i.e., index information, is also transmitted independently of the metadata fragments.
Under the environment provided by the TV-Anytime Forum, if a user desires to retrieve information on a program meeting a predetermined Published Time condition, the index information transmitted thereto independently of the fragments is utilized to identify the location (identifier) of a metadata fragment meeting a desired Published Time condition and an access to the relevant metadata fragment is then made based on the location (identifier), so as to extract metadata meeting the Published Time condition.
TV-Anytime Specification TV145, J. P. Evain, “1st Draft of Metadata Specification SP003v1.3”, TV-Anytime Forum 17th meeting, Montreal, Canada, June 2002; hereinafter, referred to as “Key index art reference” proposes a key index data stream structure for a metadata fragment index.
The notion of a container defined by the TV-Anytime Forum will be described prior to describing the index structure.
The TV-Anytime Forum defines a container as a top-level storage to which all the data covering the aforementioned index information and the metadata fragments are transmitted, which is called a type of top-level transmission. Describing the container briefly, each container comprises a plurality of sections, each storing therein the index information or the metadata fragments. The container can be classified into an index container and a data container according to the information carried thereby: the index container carries index information sections such as a key index list (key_index_list) section, a key index (key_index) section, a sub key index (sub_key_index) section, a string repository (string_repository) section and a fragment data repository (fragment_data_repository) section, whereas a data container carries metadata fragment sections such as an elements table (elements_table) section, a string repository (string_repository) section and a fragment data repository (fragment_data_repository) section. The above classification is done based on the contents of the information included in the containers. Both the index container and the data container are identical in configuration.
Referring to the container defined by the TV-Anytime Forum as illustrated in FIG. 5, the container comprises a container identifier (container_id) data field (not shown) and a large number of sections. In each section, the contents stored in ‘section_body’ are identified according to an encoded value in ‘section_id’. For example, a section 10 of which the encoded value in ‘section_id’ is ‘0X0004’ is identified as a key index list (key_index_list) section, a section 20 of which the encoded value in ‘section_id’ is ‘0X0005’ is identified as a key index (key_index) section, a section 30 of which the encoded value in ‘section id’ is ‘0X0006’ is identified as a sub key index (sub_key_index) section, a section 40 of which the encoded value in ‘section id’ is ‘0X0001’ is identified as an element table (element_table) section, and a section 50 of which the encoded value in ‘section id’ is ‘0X0003’ is identified as a fragment data repository (fragment_data_repository) section.
The TVA metadata fragments are stored in the fragment data repository (fragment_data_repository) section 50 of the data container and then transmitted. The identifier information (handle_value) for the TVA metadata fragments in the data container is included in the element table section 40 of the data container.
In conclusion, the TVA metadata fragment is uniquely identified by the container identifier information (container_id) and the metadata fragment identifier information (handle_value) of the container that includes the TVA metadata fragment.
The key index art reference described above proposes the key index structure for indexing the TVA metadata fragments stored in the aforementioned data container, i.e., a structure composed of the key index list (key_index_list) section 10, the key index (key_index) section 20, and the sub key index (sub_key_index) section 30. Since the syntax of the structure is described in detail in the key index art reference described above, the detailed description thereof will be omitted. Hereinafter, the structure will be described with reference to FIG. 6 that illustrates the structure by segments of the index information.
The key index list (key_index_list) section 10 defined in the key index structure provides a list of all the keys transmitted. The list includes key information defining each key and identification information on the key index (key_index) section 20 to be described later. The key information comprises (1) location information of the metadata fragment relevant to the key, and (2) location information of the key within the metadata fragment. The location information of the metadata fragment is expressed in XPath (fragment_xpath_ptr) in the TVA. The location information of the key is expressed in XPath (key_xpath_ptr) for the relative path within the relevant fragment of the nodes used as the key in the TVA.
The XPath of the metadata fragment is a path to the root node of the TVA metadata XML document, i.e., an absolute path, and the XPath of the nodes used as the keys, i.e., the XPath of the keys, represents a relative path of the key for the relevant metadata fragment. The XPath for the metadata fragment and the XPath for the key are stored in a ‘fragment_xpath_ptr’ segment 11 and a ‘key_xpath_ptr’ segment 12, respectively.
Furthermore, the key index list (key_index_list) section 10 includes the identification information on the key index (key_index) section 20 of each key to be described later (i.e., the container identifier information (container_id) of the container storing therein the key index (key_index) section 20 and the key index identifier information). The container identifier information and the key index identifier information are stored in an ‘index_container’ segment of the key index list (key_index_list) section 10 and a ‘key_index_identifier’ segment, respectively, and then transmitted.
The key index (key_index) section 20 defined in the key index structure provides a list of information representing the ranges of values of the key included in the respective sub key index (sub key_index) section 30, i.e., the highest value of the key among the values of the key within the respective range (hereinafter referred to as a ‘representative key value’), and identification information on the sub key index (sub_key_index) section 30 relevant to each representative key value (i.e., the container identifier information (container_id) of the container storing therein the sub key index (sub_key_index) section, and the sub key index identifier information).
Accordingly, the key index section (key_index) 20 includes a ‘key_index_identifier’ segment for storing therein the key index identifier information defined in the key index list (key_index_list) section 10, ‘high_key_value’ segments 13 for storing therein the representative key values of the respective ranges of values of the key included in the sub key index (sub_key_index) section 30, and ‘sub_index_container’ segments and ‘sub_index_identifier’ segments for the identification information on the sub key index (sub_key_index) section 30 (i.e., for the container identifier information (container_id) of the container in which the sub key index (sub_key_index) section 30 is stored, and the respective sub key index identifier information). The sub key index (sub_key_index) section 30 defined in the key index structure provides a list of the values of the key. The list further includes identification information on the metadata fragments corresponding to the values of the key (i.e., the container identifier information (container_id) of the containers storing the metadata fragments and the identifier information (handle_value) of the metadata fragments).
Accordingly, the sub key index (sub_key_index) section 30 includes a ‘sub_index_identifier’ segment for storing therein the sub key index identifier information defined in the key index (key_index) section 20, ‘key_value’ segments 14 for storing therein the respective ranges of values of the key, ‘target_container’ segments for storing therein the respective container identifier information (container_id) of the containers in which the metadata fragments are stored, and ‘target_handle’ segments for storing therein the respective fragment data identifier information (handle_value). The key index structure may be more easily understood by referring to FIG. 7 illustrating the index information.
FIG. 7 shows the key index list (key_index_list) section including keys relevant to the Service Id, the Published Time and the Published Duration. The upper node of the metadata fragment including the keys relevant to the Service Id, the Published Time and the Published Duration is ‘BroadcastEvent’ 310 as shown in FIG. 3, identified by a shaded block. Accordingly, the XPath ‘/TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent’ for the ‘BroadcastEvent’ fragment is stored in the ‘fragment_xpath_ptr’ segment 11a, and the XPaths to the keys of the Service Id, the Published Time and the Published Duration for the ‘BroadcastEvent’ fragment, i.e., ‘@ServiceId’ (311a in FIG. 3), ‘EventDescription/PublishedTime’ (311b in FIG. 3) and ‘EventDescription/PublishedDuration’ (311c in FIG. 3) are stored in the ‘key_xpath_ptr’ segment 12a. 
The index structure will be more comprehensible with reference to FIG. 7 which illustrates the index information.
FIG. 7 shows the key index list (key_index_list) section including keys for Service ID, Published Time and Published Duration, wherein a upper node of the metadata related to the Service ID, the Published Time and the Published Duration is ‘BroadcastEvent’ 310 indicated as a shaded portion in FIG. 3. Accordingly, the XPath for the ‘BroadcastEvent’ fragment, ‘/TVAMain/ProgramDescription/ProgramLocationTable/BroadcastEvent’ is stored in the ‘fragment_xpath_ptr’ segment, and the respective XPaths for keys of Service ID, Published Time and Published Duration for the ‘BroadcastEvent’ fragment, ‘@ServiceID’ (see 311a of FIG. 3), ‘EventDescription/PublishedTime’ (see 311b of FIG. 3), and ‘EventDescription/PublishedDuration’ (see 311c of FIG. 3) are stored in the ‘key_xpath_ptr’ segment.
Also, FIG. 7 shows the key index (key_index) section 20 and the sub key index (sub_key_index) section 30 for the Service ID (the XPath of the key: @ServiceID) of the key index list (key_index_list) section 10.
In such an index structure, when a search condition for searching the metadata is input, location information on a field of the input search condition in the metadata is determined and the determined location information is compared to the key information in the key index list so as to search the key having the determined location information within the key index list, overhead is caused since comparison of both Xpaths is necessary. The same problem occurs when the keys indicating relative paths from the fragments among the key information are compared in terms of location information. Particularly, this problem becomes more severe when fragments, which are more complex than the keys, are compared in terms of location information. Since the XPath of the fragment representing location information among key information describes a path to a relevant node from the root node on the XML document, transmission costs are inefficient and interpretation costs of the XPath in the terminal are high. For example, the XPath of the broadcast event fragment indicating location information of a program among the TV-Anytime fragments can be expressed as /TVAMain/ProgramDescription/ProgramLocationTable/BroadcastEvent’. Meanwhile, in order to represent one node on the XML document, the XPath can be expressed in an alternative manner. In the case of a broadcast event, in addition to the aforementioned normal representation, the XPath can be expressed alternatively, such as ‘/TVAMain//BroadcastEvent’ or ‘//BroadcastEvent,’ and so on. Herein, ‘//’ means a child node in the structure of an XML document. Therefore, an operation to inspect whether fragments are the same by use of the XPath is not a simple one that merely matches simple strings with each other. In particular, overhead is caused in analysis/comparison of the relevant path, if the XPath path is expressed in an abbreviated format.